This invention relates to a tool attachable to a controller.
As is well known, control systems for use in industries are usually formed by appropriately combining controllers such as a PLC and devices which are controlled by such controllers. FIG. 1 shows a prior art example of such a system comprising a controller 1 to which a plurality of devices 3a, 3b are connected through a network 2. Control programs (also referred to as drivers) 4a, 4b for handling the devices 3a and 3b are installed in the controller 1. These control programs 4a, 4b are prepared individually for these devices 3a, 3b and serve to transmit and receive data to and from the corresponding one of the devices 3a, 3b by making use of an I/O memory 5 in order to carry out a specified process. Numeral 6 indicates a control program (X) for retrieving the control programs 4a, 4b. They may altogether form a task.
The devices 3a, 3b may be of different types. They may be of a type, such as ON/OFF sensors and digital I/O, serving to transmit and receive ON/OFF data to and from the controller 1. They may be of another type, such as photoelectric sensors (having the quantity of light and a threshold value as parameters) or temperature adjusters (having a target temperature and PID as parameters), having parameters to be set within the device and operated by a program prepared by the user.
Although FIG. 1 shows an example with the devices 3a, 3b connected to the controller 1 through a network 2, communications between devices and a controller may be effected through a bus within the controller. This would be a case if a building block-type PLC is used as the controller and motion control units and PID control units are directly connected to the slots on its base unit.
For carrying out such communications, it is necessary to correlate the control programs 4a, 4b with the devices 3a, 3b to be accessed thereby. For this purpose, it is normally done to assign node numbers serving as identifiers to be uniquely set on the network 2 for the devices 3a, 3b and to specify these node numbers to make an access. When the devices are connected through a bus, the node numbers become unit numbers, but the basic idea remains the same.
For the example shown in FIG. 1, the node number of Device A 3a is #5 and that of Device B 3b is #6. Thus, when Control Program A 4a makes an access to Device A 3a by message communication, the node number #5 for Device A 3a is written in the program.
It is convenient if a control program, after having been created, can be used again (“reuse”) for another program because the trouble of creating a completely new program can be obviated and the labor for the development can be reduced. On the other hand, however, a control program (referred to as a driver) can manifest its usefulness only after this control program (software) is integrated into the device (hardware) to be accessed and it is preferable to treat the software and the hardware together. When a control program and a device is thus integrated together, it is hereinafter referred to as a “control object” or simply as an “object”.
With prior art systems, however, there was no way to treat a control program and a device as an integrated object although individual programs could be reused in units of programs. Thus, the programs were reused only separately, and it was a cumbersome process.
It also happens sometimes, as shown in FIG. 1, to reconnect a device (such as Device A 3a which has been in use with a controller 1) to another controller 1′ and to use it therewith, say, for changing, reinforcing or repairing a production line. If the user remembers the concept of control object introduced above and attempts to shift both the control program and the device to the reusing controller 1′, the control program can be easily downloaded to the controller through a programming tool or a memory card provided to the controller, and the device (such as Device A 3a) can be shifted as hardware by connecting to the network 2′ to which the controller 1′ is connected.
With such a simple connection, however, the control object cannot be made operable. Although a configuration is required for carrying out communications with the device paired with the control program, the data which were being used by the controller 1 cannot be directly used for the operation.
This will be explained more in detail with reference to the example of FIG. 1. In this case, the node number of Device A controlled by Control Object A 4a was #5, to start with. Thus, Control Program A or Control Program X for retrieving Control Program A includes a portion where the node number #5 is specified for accessing Device A. In the reusing controller 1′, however, the node number #5 is already used by another device. Thus, there will be an error if the portion of Control Program A or X containing the node number #5 is left unmodified. In the case of the example shown in FIG. 1, therefore, the portion of Control Program A or X must be modified to rewrite #5 as #2, which is the correct node number. This must be done, however, with extreme care such that the rewriting will not affect other programs.
It also happens sometimes that Device A is assigned differently in the I/O memories of the controllers I and I′ (I/O configuration). Even if the programming style is such that the I/O memory 5 to which Device A is assigned to is accessed by specifying its address or by a variable programming, relevant portions of the program must be modified in view of the possibility that the assignment may have been changed at the time of a reuse. This makes the procedure cumbersome, and the operation cannot proceed if a wrong address is used.
There are also additional problems if a reassignment to the I/O memory 5 is required, as explained above, when a control object is to be reused, because the program developer must be aware of how the I/O memory 5 of the reusing controller 1′ is being used, or the memory map showing where to find an empty area of a specified size. In other words, the program must be prepared such that empty areas can be efficiently utilized. During this process, human errors such as erroneous assignment are likely to take place.
It also happens sometimes that even the I/O assignment for an already assigned device is changed. In such a situation, the control program for the already connected device must be modified. Not only is this cumbersome but it also tends to increase the possibility of introducing errors.
As explained above, furthermore, there are devices such as photoelectric sensors and temperature adjusters that are provided with parameters to be set within the device. For setting such parameters and programs for such a device, it may be necessary to attach tools directly to the device or to the controller and to carry out setting of different kinds through such a controller.
Thus, if a device malfunctions and is replaced, the same work procedure that was carried out on the replaced device such as the setting of parameters must be repeated over again on the new replacing device. Such procedure is usually carried out manually by an operator according to data recorded either in a memory device or in a notebook. This means that input errors are likely to occur. It also happens frequently that such data are misplaced or otherwise difficult to find immediately or wrong data are erroneously consulted.
FIG. 2 shows another prior art system. If an error occurs in the device 3 in this system, there is a change in a bit in the I/O memory 5 of the controller 1 assigned to the device 3. If this change is detected by a display device 7 which keeps monitoring the I/O memory 5 of the controller 1, an error warning is outputted thereby. Explained more in detail, the condition of the device 3 is detected by system software (First Communication Process 8a, or “COMM PROC 1”) of the controller 1 and is stored at a preliminarily specified address on the I/O memory 5 of the controller 1. A control program 4 in the controller 1 is monitoring this address of the I/O memory 5, and if a change in the condition (such as the “flag” condition) at this address is detected, the control program 4 indicates it at another address(say, by raising a flag at this address). When this happens, the control program 4 causes data such as the screen number to be displayed on the display device, numeral data such as an abnormality code and character array data (such as the details of the abnormality) to be stored in a specified area on the memory 5 according to the condition of the device. Such data are then transmitted to the display device 7 through the Second Communication Process (or “COMM PROC 2”) 8b and stored in the memory 5 inside the display device 7 according to data received by its communication processing means (or “COMM PROC”) 8c. The screen number at which the display is to be made on the display device 7 is retrieved by the image display processing means (“IMAGE DISPLAY PROCESS”) 4c together with the data stored in the memory 5. As a corresponding image is retrieved from the image memory 9, the retrieved image is displayed.
Even if an abnormal condition in a certain device is thus indicated, however, it cannot be readily understood from the display what is the role being played by the device within the system. For example, the user may recognize a logical unit called “Robot” but if it is reported that there is an abnormality in a communication address of a device which is its constituent element or that there is an ON/OFF error at a certain bit of the controller to which the device is assigned, it is not easy at all to understand in what kind of control element an abnormality has occurred. Thus, it is usually required to consult a table of some kind to understand the logical meaning and to carry out a proper maintenance work.
Production lines include many pieces of equipment, each provided with a so-called human-machine interface (HMI) such as display devices and panel computers. When the value of a device connected to a controller is to be displayed, if the memory of the device is connected to the memory of the controller, the HMI consults the memory of is the controller to which the device is connected through communication and its value is displayed by the HMI. If calculations are required for the display, such calculations are usually carried out by a HMI suited for carrying out data-related programs.
From the points of view of program designers who design programs for HMI and display images and users who watch such HMI, it is desirable to collect data on devices by making an access with an object name for easy understanding. With a prior art system such as shown in FIG. 2, however, the user will initially have to map the memory of the device to the controller by I/O configuration and, after understanding its data, to use a tool of the HMI to specify the address of the memory of the controller.
Thus, if the memory of the device has been changed, say, as a result of an equipment change, the calculation program of the HMI must also be rewritten. Thus, when a control program and a data program are to be developed concurrently in parallel, the developer of one program must always be attentive of the development in the other program. This makes the development of various programs very complicated and time-consuming.